FIG. 1 is a block diagram illustrating a typical prior art graphics system with two graphics applications and three display adapters. A first graphics application 100 is shown as a two dimensional (2-D) graphics software package and a second graphics application 110 is shown as a three dimensional (3-D) graphics software package. Both graphics applications 100 and 110 depend on an application programming interface (API) 120 and 130, respectively, for communicating with display adapters 170, 180 and 190. The APIs define the function and control of the display adapters expected by the applications, and provide a more abstract or more powerful method of managing graphics than is possible when programming directly to the display adapters. In the prior art, the APIs 120 and 130 typically contain the code forming the device drivers 126, 132, 134, and 136 for display adapters 170, 180 and 190.
In the prior art, an application program is typically unaware of the flow of information from the API to the display adapter. This simplifies the programming and use of the application program. For example, 2D graphics application 100 communicates to display adapter B 180 by transmitting information through API 120. The API then transmits the information through its internal device driver 126 to the adapter 180. In the prior art, application 100 is typically not aware of data flow between API 120 and internal device driver 126 and between the device driver 126 and the display adapter 180.
FIG. 2 is a block diagram of more recent prior art technology as described in U.S. patent application Ser. No. 07/478,384 filed Feb. 12, 1990 entitled "Display Subsystem Architecture Having a Graphics Adapter Interface" which was abandoned on Jan. 4, 1993 and continued as application Ser. No. 08/000,823 which was abandoned on Nov. 18, 1994 and continued as application Ser. No. 08/341,858. This graphics system may include three graphics applications 200, 205 and 210. In this example, the three graphics applications are MIT's X-Windows, Silicon Graphics, Inc. GL, and IBM's graphics. Each of the applications has been designed to use an appropriate API 220, 225 and 230. The APIs each communicate with a graphics adapter interface (herein referred to as GAI) 300. The APIs each contain and utilize a single GAI driver 221,226, and 231 for communicating with the various device driver libraries 320, 330 and 340 of GAI 300. The GAI device driver libraries 320, 330, 340 then communicate with display adapters 260, 265 and 270. In this example, the device driver libraries are known as the GAI 2-D Library 320, the GAI 3DM1 Library 330, and the GAI 3DM2 Library 340. The GAI libraries each contain and utilize display adapter specific code 321, 322, 323, 331, 332, 333,341, 342, 343 for each display adapter. All of the device specific display drivers within a given GAI device driver library share a common programming interface to a particular API. In the given example, GAI libraries 320, 330 and 340 utilize library interfaces 2-D 325, 3DM1 335 and 3DM2 345.
Each GAI Library contains a number of device specific display drivers. For example, the GAI 2-D Library 320, display drivers 321, 322, and 323 are written for target display adapters 260, 265, and 270, respectively. In the prior art, when an application causes the API to select a GAI Library, the API also selects which display driver in the GAI library is the target. For example, if the GL application 205 was executing on a machine which contained display adapter B 265, then the GL application 205 would use the 3D API 225. The API 225 would contain the GAI device driver 226. The interaction of 226 and the GAI 300 would cause GAI 3DM2 Library 340 to be selected. The programming interface and functionality of the GAI Library 3DM2 340 would be realized in the dynamic binding of the GAI device driver 226 to the device specific code of display driver 342 targeted for display adapter 265.